home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / bbs / rfc / rfcxxx_2.lha / RFCxxx / rfc898 < prev    next >
Text File  |  1995-07-26  |  42KB  |  1,393 lines

  1.  
  2.  
  3. Network Working Group                                    R. Hinden (BBN)
  4. Request for Comments: 898                                J. Postel (ISI)
  5.                                                           M. Muuss (BRL)
  6.                                                        J. Reynolds (ISI)
  7.                                                               April 1984
  8.  
  9.               GATEWAY SPECIAL INTEREST GROUP MEETING NOTES
  10.  
  11. STATUS OF THIS MEMO
  12.  
  13.    This memo is a report on a meeting.  No conclusions, decisions, or
  14.    policy statements are documented in this note.
  15.  
  16. INTRODUCTION
  17.  
  18.    This memo is a report on the Gateway Special Interest Group Meeting
  19.    that was held at ISI in Marina del Rey, California on 28 and 29
  20.    February 1984.  Robert Hinden of BBNCC chaired, and Jon Postel of ISI
  21.    hosted the conference.  Approximately 35 gateway designers and
  22.    implementors attended.  These notes are based on the recollections of
  23.    Jon Postel and Mike Muuss.  Under each topic area are Jon Postel's
  24.    brief notes, and additional details from Mike Muuss.
  25.  
  26.    The rest of this memo has three sections: the agenda, notes on the
  27.    talks, and the attendees list.
  28.  
  29. MEETING AGENDA
  30.  
  31.    Tuesday, February 28
  32.  
  33.       9:00  Opening Remarks -- BBN - Hinden
  34.       9:15  Opening Remarks -- ISI - Postel
  35.       9:30  The MIT C Gateway -- MIT - Martin
  36.       10:00 The Butterfly Gateway -- BBN - Hinden
  37.       10:30 Break
  38.       11:00 The EGP C Gateway -- ISI - Kirton
  39.       11:20 The BRL Gateway -- BRL - Natalie
  40.       11:40 The CMU Gateway -- CMU - Accetta
  41.       12:00 Lunch
  42.       1:30  The Wisconsin BITNET/CSNET Gateway -- UWisc - Solomon
  43.       2:00  LAN to X.25 Gateway -- Computer Gateways Inc. - Buhr
  44.       2:20  ISI-UCI Gateway -- UCI - Rose
  45.       2:40  FACC Gateway -- FACC - Holkenbrink
  46.       3:00  Break
  47.       3:30  Lincoln IP/ST Gateway -- LL - Forgie/Kantrowitz
  48.       3:50  Minimal Stub Gateways -- MITRE - Nabielsky
  49.       4:10  Discussion
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57. Hinden, Postel, Muuss, & Reynolds                               [Page 1]
  58.  
  59.  
  60.  
  61. RFC 898                                                       April 1984
  62. Gateway SIG Meeting Notes
  63.  
  64.  
  65.    Wednesday, February 29
  66.  
  67.       9:00  Opening Remarks -- BBN - Hinden
  68.       9:10  SPF routing -- BBN - Seamonson
  69.       9:35  Multiple Constraint Routing -- SRI - Shacham
  70.       10:00 FACC Multinet Gateway Routing -- FACC - Cook
  71.       10:30 Break
  72.       11:00 Metanet Gateway -- SRI - Denny
  73.       11:20 Address Mapping and Translation -- UCL - Crowcroft
  74.       11:40 Design of the FACC Multinet Gateway -- FACC - Cook
  75.       12:00 Lunch
  76.       1:30  SAC Gateway -- SRI - Su/Lewis
  77.       2:00  EGP -- Linkabit - Mills
  78.       2:30  Congestion Control -- FACC - Nagle
  79.       3:00  Break
  80.       3:30  A Gateway Congestion Control Policy--NW Systems - Niznik
  81.       4:00  Discussion
  82.  
  83. NOTES ON THE MEETING
  84.  
  85.    The MIT C Gateway -- MIT - Martin
  86.  
  87.       Postel:  A description of the gateway implemented at MIT.  The
  88.       gateway was first developed by Noel Chiappa.  It is written in C.
  89.       The MIT environment has 32 internal networks which are treated as
  90.       subnets of the MITNET on the Internet.  The MIT gateways then do
  91.       subnet routing in their interior protocol.  The subnet routing
  92.       scheme is similar to GGP.  Liza has added an EGP implementation to
  93.       this gateway.
  94.  
  95.       Muuss:
  96.  
  97.       Campus network/project Athena
  98.       Dynamic routing
  99.       Congestion control - grad student
  100.                       +---------------+---+
  101.        Class A net  : | 18|subnet|res|host|
  102.                       +---------------+---+
  103.  
  104.       "Bridges" forward between subnets.
  105.  
  106.       Campus Network and Project Athena 65 VAX 750s, 200 IBM PCs.
  107.  
  108.       Hosts: Now = 400, 1986 = 3,000, 1990 = 10,000
  109.  
  110.       Subnets: Now = 42, 1985 = 60, 1990 = 200, (4 subnets/building)
  111.  
  112.       Protocols: Internet, DECnet, Chaosnet
  113.  
  114.  
  115. Hinden, Postel, Muuss, & Reynolds                               [Page 2]
  116.  
  117.  
  118.  
  119. RFC 898                                                       April 1984
  120. Gateway SIG Meeting Notes
  121.  
  122.  
  123.       FiberOptic spine between campus buildings.
  124.  
  125.       MIT gateways:
  126.  
  127.          11/03s and 11/23s
  128.          68000 on Abus
  129.          6800 on Multibus (Bridge communications)
  130.  
  131.          MIT C gateway -
  132.          Runs under MOS, bridge OS, homegrown OS. Multiple protocols,
  133.          multiple interfaces.
  134.  
  135.          11/03 - 100 packets/sec.
  136.          11/23 - 180 packets/sec.
  137.  
  138.          GGP - Gw/Gw
  139.          EGP - Exterior Gw
  140.          IGP - Interior Gw
  141.  
  142.          EGP:  Autonomous systems
  143.  
  144.          EGP:
  145.            Neighbor acquisition
  146.            Hello/I heard you
  147.            Net reachability poll
  148.            Net reachability message
  149.  
  150.       MIT IGP:
  151.  
  152.          IP header on EGP protocol
  153.          Dest: net number, subnet number, 0, 0377 (broadcast address)
  154.  
  155.       IGP header:
  156.  
  157.          Autonomous system number
  158.          Sequence number
  159.          Tasks:
  160.              Propagate exterior and subnet routing.
  161.  
  162.       Packets
  163.          Ext route request, and update Routing server
  164.              Default gateway
  165.              Exceptional gateways
  166.              Nets reached
  167.  
  168.       MIT - Gw broadcasts initial routings when it comes up, and again
  169.       on each change, net is flooded on each change several times. Each
  170.       bridge can ask for help.
  171.  
  172.  
  173. Hinden, Postel, Muuss, & Reynolds                               [Page 3]
  174.  
  175.  
  176.  
  177. RFC 898                                                       April 1984
  178. Gateway SIG Meeting Notes
  179.  
  180.  
  181.       Future:  Wideband net gateway from BBN will also sit on net  18,
  182.       and an MIT routing server to acquire routing information. Trick -
  183.       BBN-Gw will be on an Ethernet, and a modified ARP will be used by
  184.       the bridges to "fool" the BBN gateway into acquiring the routes.
  185.  
  186.       Subnet Routing - inspired by PUP and CHAOS
  187.          Neighbor Bridge
  188.            Net I/F
  189.            Bridge address
  190.            Latest seq number
  191.            Aging value
  192.          Route to subnet
  193.            Distance
  194.  
  195.          Packets
  196.            Request
  197.            I'm up
  198.  
  199.              Route update
  200.                Distance vector (256 bytes)
  201.                        0 - Direct
  202.                        1 -127 - hop count
  203.                        128-255 - "Interface used for next hop" to subnet
  204.                                  and hop count
  205.                        255 - Unreachable
  206.  
  207.       Problem -
  208.          Many neighbors --> too much time and traffic needed for
  209.       processing.
  210.       
  211.          3 level addressing and routing strategy
  212.          Ext Gw:
  213.            Routing server
  214.            Default Gw
  215.          Subnet routing
  216.            Small but rich subnet routing updates.
  217.  
  218.    The Butterfly Gateway -- BBN - Hinden
  219.  
  220.       Postel:  A description of the butterfly hardware and a discussion
  221.       of the plans for the new gateway software to be implemented on it.
  222.       The butterfly machine is a multiprocessor (MC68000's)
  223.       interconnected with a funny switch.  The new software will
  224.       incorporate the so called "Shortest Path First" or SPF routing
  225.       algorithm.
  226.  
  227.  
  228.  
  229.  
  230.  
  231. Hinden, Postel, Muuss, & Reynolds                               [Page 4]
  232.  
  233.  
  234.  
  235. RFC 898                                                       April 1984
  236. Gateway SIG Meeting Notes
  237.  
  238.  
  239.       Muuss:
  240.  
  241.       Replacement for existing 30 PDP-11 "core" gateways.
  242.       Problems to be solved.
  243.  
  244.          o  Replace GGP
  245.               - Routing updates filling up
  246.               - Neighbor probes (N**2)
  247.               - Few buffers
  248.  
  249.          o  Present GGP updates only hold 70 net numbers, repacking
  250.             data will increase that to approximately 100 nets, but
  251.             this is just short term.
  252.  
  253.       Features of Butterfly -
  254.          o  1000's of nets
  255.          o  Partitioned nets
  256.          o  Type of service routing, access control
  257.          o  Flow control
  258.          o  Large and small gateway configurations
  259.  
  260.       New functions -
  261.          o  Routing
  262.          o  Neighbor discovery
  263.          o  Reduce neighbor pinging
  264.          o  Access/departure model
  265.          o  Connect gateways with point-to-point lines
  266.  
  267.       Routing -
  268.          o  SPF - shortest path first
  269.          o  Gateway based routing (opposed to network routing)
  270.          o  Routing updates
  271.               Gw ID
  272.               <nets directly connected>
  273.               <neighbor, distance>
  274.          o  Updates flooded to other gateways
  275.  
  276.       Next-door - Neighbors
  277.          o  Neighbor gateways closest to gateway
  278.          o  Ping next-door-neighbors only
  279.          o  For up/down acquisition, partition into rings.  Reduces
  280.             pinging.
  281.       
  282.       Access/departure model
  283.       
  284.           First Gw (entrance) picks exit gateway
  285.  
  286.  
  287.  
  288.  
  289. Hinden, Postel, Muuss, & Reynolds                               [Page 5]
  290.  
  291.  
  292.  
  293. RFC 898                                                       April 1984
  294. Gateway SIG Meeting Notes
  295.  
  296.  
  297.           First Gw adds Gw - Gw header
  298.       
  299.       Butterfly gateway
  300.  
  301.           Processor nodes and switch nodes
  302.          
  303.           4-legged switch nodes, decision is simply UP or DOWN.  2
  304.          inputs
  305.           and 2 outputs.
  306.  
  307.           Processor:  MC 68000
  308.           Memory management Unit
  309.           Processor node controller - 2901 bit slice
  310.           PVC is the memory controller.
  311.  
  312.          Butterfly -
  313.           32 M bps/path
  314.           Bandwith:   approximately N - speed
  315.           Size:       approximately N/2   log  N 2
  316.  
  317.          Butterfly will support multibus interface; 1822, HDLC,
  318.          Ethernet, Ring
  319.  
  320.       Terminal and load device will be a personal computer
  321.  
  322.       Small Gw for ARPA is approximately $20K
  323.  
  324.       New Gw processor structure
  325.  
  326.       Buffer Management
  327.         o   Scatter/gather buffers minimum size and extensions
  328.         o   Buffer pool on processors with I/O
  329.         o   Primary and secondary collections per device
  330.              ==>  guaranteed minimum service per device
  331.                   (implemented w/counts)
  332.  
  333.    The EGP C Gateway -- ISI - Kirton
  334.  
  335.       Postel:  A user process was installed in Berkeley 4.2 Unix to do
  336.       EGP protocol functions leaving the normal router kernel function
  337.       in charge of forwarding datagrams.  The EGP user process may do
  338.       system calls to update the kernel routing data.  Based on the work
  339.       of Liza Martin.
  340.  
  341.  
  342.  
  343.  
  344.  
  345.  
  346.  
  347. Hinden, Postel, Muuss, & Reynolds                               [Page 6]
  348.  
  349.  
  350.  
  351. RFC 898                                                       April 1984
  352. Gateway SIG Meeting Notes
  353.  
  354.  
  355.       Muuss:
  356.  
  357.       EGP under 4.2
  358.  
  359.       Elimination of nonrouting gateways
  360.  
  361.       Design -
  362.           Forwarding done in kernel
  363.           Kernel does not send redirects
  364.           EGP user process for route updates
  365.           Written in C
  366.           EGP based on Liza Martin's code
  367.  
  368.       Routing Tables
  369.         o   Kernel
  370.         o   EGP Process
  371.  
  372.       EGP Process Table -
  373.         o   External updates
  374.         o   Internal information
  375.  
  376.       Facilities -
  377.  
  378.          Configuration file-
  379.              o   Trusted neighbors
  380.              o   Internal non - routing gateways
  381.  
  382.          Acquisition -
  383.            o   Predetermined number of core gateways are EGP'd to
  384.            o   Only accept from trusted neighbors
  385.            o   Cannot acquire neighbors indirectly, for now
  386.  
  387.          Unix Interfaces -
  388.            Reuse IP socket (problem with protocol number)
  389.            Listening to ICMP for redirects
  390.            System calls for -
  391.              o   Route updates
  392.              o   I/F config reading
  393.              o   I/F status check
  394.  
  395.          Performance -
  396.              o   60 ms/packet pair (CPU time)
  397.              o   Typically 1% of CPU for 1 minute polling
  398.  
  399.          Protocol function going
  400.          Routing updates being implemented
  401.  
  402.          Should be all going in April.
  403.  
  404.  
  405. Hinden, Postel, Muuss, & Reynolds                               [Page 7]
  406.  
  407.  
  408.  
  409. RFC 898                                                       April 1984
  410. Gateway SIG Meeting Notes
  411.  
  412.  
  413.    The BRL Gateway -- BRL - Natalie
  414.  
  415.       Postel:  This was a description of the BRL dumb gateway.  More
  416.       interesting was the description of the BRL complex and the
  417.       inteconnections between machines.  The gateway is written in C
  418.       (and derived from the MIT C-Gateway) and based on a simple
  419.       multiprocess operating system called LOS.
  420.  
  421.       Muuss:
  422.  
  423.       BRL history
  424.       
  425.       LOS design
  426.         Message passing
  427.         Memory Management
  428.         No copying of data, buffer size
  429.  
  430.    The CMU Gateway -- CMU - Accetta
  431.  
  432.       Postel:  This was a description of the CMU dumb gateway.
  433.  
  434.       Muuss:
  435.  
  436.       History -
  437.         o   "Logical-Host" multiplexor (March 81)
  438.         o   Gateway (Oct 82) remote debugger and monitor
  439.         o   Router (Oct 83)
  440.               - Modular device and protocol support
  441.               - Stub IP dynamic routing
  442.               - Local inter-network cable routing.
  443.         o   Written in "C"
  444.  
  445.       Uses low memory for buffers (maximum 32K)!
  446.         (autoboot of 3M bps Ethernet)
  447.       Auto-configuration of devices
  448.       Individual stack contents
  449.       Round-robin scheduler
  450.       Dynamic memory allocation
  451.  
  452.       Device driver
  453.         Network interfaces
  454.         Auxiliary support devices
  455.  
  456.       Does IP, ICMP, UDP
  457.  
  458.          Splicing through of PUP and CHAOS on chaos net, uses ARP.
  459.  
  460.          Configuration testing protocol (as in Ethernet Spec).
  461.  
  462.  
  463. Hinden, Postel, Muuss, & Reynolds                               [Page 8]
  464.  
  465.  
  466.  
  467. RFC 898                                                       April 1984
  468. Gateway SIG Meeting Notes
  469.  
  470.  
  471.          IP Processing-
  472.  
  473.             o   Consistency checks
  474.             o   Redirects does not forward misrouted packets
  475.             o   Fragmentation - ICMP dest unreach If DF Set
  476.             o   Access list for who can pass through
  477.  
  478.          No GGP, no EGP, Uses known gateways
  479.  
  480.          Ordinary devices and PDP-10 and PDP-20
  481.  
  482.    The Wisconsin BITNET/CSNET Gateway -- UWisc - Solomon
  483.  
  484.       Postel:  This was a discussion of a mail relay between the
  485.       Internet and BITNET to be installed at Wisconsin.
  486.  
  487.       Muuss:
  488.  
  489.       WISC-IBM (192.5.2.24) will connect to BITNET
  490.  
  491.       Mail gateway, BITNET uses RFC 822 headers!
  492.  
  493.    LAN to X.25 Gateway -- Computer Gateways Inc. - Buhr
  494.  
  495.       Postel:  This was a description of a protocol translation device
  496.       between an X.25 world and the DATAPOINT ARCNET world.
  497.  
  498.       Muuss:
  499.  
  500.       ARCNET to X.25 Bridge
  501.       
  502.       ARCNET - from Datapoint,
  503.         Baseband coax, 2.5 mbps
  504.         Token passing
  505.         Reserve/send/wait/ack protocol
  506.         RIM chip implements this
  507.  
  508.       "The OSI models seem less clear than the Internet models, perhaps
  509.       because they are less well developed."
  510.  
  511.       Wraps the subnetwork in an enhanced subnetwork layer.
  512.  
  513.       Every pair of subnetworks must be connected in this design - hence
  514.       a bridge not a gateway.
  515.  
  516.       Bridge is a network layer RELAY.
  517.  
  518.       ARCNET address is sent as X.25 data
  519.  
  520.  
  521. Hinden, Postel, Muuss, & Reynolds                               [Page 9]
  522.  
  523.  
  524.  
  525. RFC 898                                                       April 1984
  526. Gateway SIG Meeting Notes
  527.  
  528.  
  529.    ISI-UCI Gateway -- UCI - Rose
  530.  
  531.       Postel:  This was a description of the UCI dumb gateway. This one
  532.       is made up of two hosts (VAX 750s) 50 miles apart.  The VAXs are
  533.       connected via a 9.6 Kbs leased line.  One is interfaced to the
  534.       ISI-NET (an Ethernet) and the other to UCIICS net (also an
  535.       Ethernet).  The VAXs run Berkeley Unix 4.1.  These VAXs run as
  536.       regular hosts too.
  537.  
  538.       Muuss:
  539.  
  540.       MTU is 512. Effective bandwidth of approximately 6000 baud over
  541.       9600 baud line.
  542.  
  543.    FACC Gateway -- FACC - Holkenbrink
  544.  
  545.       Postel:  A description of a gateway designed by Ford.  The gateway
  546.       is based on a MC68000 multiprocessor and a VME bus.  An
  547.       interesting question that came up during this presentation  was
  548.       "What is the least information a host (or gateway) must have when
  549.       it comes up, and how can it acquire the rest of what it needs to
  550.       go into full operation from the environment?"
  551.  
  552.       Muuss:
  553.  
  554.       Inter-segment Processor. M68000 CPU with various co-processors.
  555.       68000 IOPS, 1822, IOP Ethernet IOP. 1 cpu does IP, routing.
  556.       Multi-cpu version of MOS
  557.  
  558.    Lincoln IP/ST Gateway -- LL - Forgie/Kantrowitz
  559.  
  560.       Postel:  This was a discussion of the design of the Lincoln
  561.       gateways used primarily in the WBCNET for speech transmission
  562.       research.  This gateway uses special I/O interfaces to promote a
  563.       high packet processing rate.  The gateway implements both the
  564.       regular IP, and the ST protocol which permits resource
  565.       reservations to minimize the variation in transmission delay.
  566.       These gateways can, of course, act as regular internet gateways,
  567.       and have achieved very good performance in terms of datagrams per
  568.       second.
  569.  
  570.       Muuss:
  571.  
  572.       Packet voice experiments, wideband SATNET. Concentrate traffic
  573.       from local nets to trunk net. Needed enough performance to load
  574.       WBSATNET. 11/44 and ACC IF11 (Z-80). T1 trunk protocol converter.
  575.       (voice T1 <--> datagram)
  576.       
  577.  
  578.  
  579. Hinden, Postel, Muuss, & Reynolds                              [Page 10]
  580.  
  581.  
  582.  
  583. RFC 898                                                       April 1984
  584. Gateway SIG Meeting Notes
  585.  
  586.  
  587.       IP problems -
  588.         o   Congestion
  589.         o   High packet header overhead
  590.         o   No support for conference call
  591.  
  592.       ST -
  593.         o   Virtual circuit
  594.         o   Know capacity in advance, schedule channel
  595.         o   Abbreviated header
  596.  
  597.       11/44 - 900 to 1000 pkts/sec.
  598.       
  599.       Port processor:
  600.         Sync low speed:     600K bits/sec.
  601.         Packet processing:  500 pkts/sec. average
  602.           20-talker LPC voice loop, 28 data
  603.             bytes/pkt, 50% duty cycle
  604.         Data handling
  605.           4 pcm voice stream loop  64K bps
  606.           184 data bytes/pkt, 100% duty cycle
  607.  
  608.       Dispatcher Requirements
  609.         o  Timely do ST
  610.         o  Utilize rest of circuit for IP
  611.         o  Performance measurement
  612.  
  613.       Reservations on the SATNET: Each host makes a reservation for
  614.       Nbytes of M messages every INTERVAL. Reservations are absolute.
  615.  
  616.       ST and IP for each distant run = MPP multipurpose packets.
  617.  
  618.       12,000 lines of C code in 11/44 portion.
  619.  
  620.    Minimal Stub Gateways -- MITRE - Nabielsky
  621.  
  622.       Postel:  This was a more abstract discussion of how stub gateways
  623.       could interact and acquire information about the topology of the
  624.       Internet.
  625.  
  626.       Muuss:
  627.  
  628.       Ethernet stub to Internet
  629.       Inexpensive, single-band  ISBC  186/51 Intel @ $3000
  630.       High performance.  EGP?
  631.  
  632.       128K bytes/board
  633.  
  634.       The Internet forest
  635.  
  636.  
  637. Hinden, Postel, Muuss, & Reynolds                              [Page 11]
  638.  
  639.  
  640.  
  641. RFC 898                                                       April 1984
  642. Gateway SIG Meeting Notes
  643.  
  644.  
  645.       Alternative to ARP using Multicast
  646.  
  647.    SPF routing -- BBN - Seamonson
  648.  
  649.       Postel:  This was a fine presentation of the principles of the
  650.       "Shortest Path First" (SPF) routing procedures with some remarks
  651.       on how it is tailored to the Internet gateway situation.  One
  652.       point that was impressed on me was that when using SPF in a set of
  653.       gateways (say, the core autonomous system) the procedure will do
  654.       routing to an "exit" gateway.  Somehow I had not thought about it
  655.       in those terms before, but (obviously) just as there is a source
  656.       and a destination IMP in the ARPANET there will be an entrance and
  657.       an exit gateway in an SPF autonomous system.
  658.  
  659.       Muuss:
  660.  
  661.       Features -
  662.         Metric, update procedures, path calculation, forwarding
  663.  
  664.       Current GGP problems -
  665.         o   Counting to infinity
  666.         o   Not enough topology information in each Gw
  667.         o   Updates potentially very large
  668.  
  669.       SPF in ARPANET
  670.         o   Single path (not optimal) - no split of flow
  671.         o   Delay based, to minimize delay
  672.         o   Global knowledge of connection topology and delays
  673.  
  674.       Metric used -
  675.         o   Delay, delay of each packet averaged
  676.               (queueing plus transmission plus propagation)
  677.               arrival-to-arrival time.
  678.         o   Average delay on each trunk computed every 9.6 seconds.
  679.             Report large changes in delay, fast
  680.  
  681.       Update procedure -
  682.         o   Updates report delay to each neighbor
  683.         o   Update triggered by topology change, significant delay
  684.             change, or 1 time/minute.
  685.             Decay of threshold to direct to send update
  686.         o   Sequence numbers
  687.         o   Flooding on all trunks sent out on all lines
  688.         o   Receipt of echo is acknowledgement
  689.         o   Retransmission
  690.         o   Aging of information
  691.         o   Updates are 2*n*l packet growth.  n = number imps,
  692.             l = number lines
  693.  
  694.  
  695. Hinden, Postel, Muuss, & Reynolds                              [Page 12]
  696.  
  697.  
  698.  
  699. RFC 898                                                       April 1984
  700. Gateway SIG Meeting Notes
  701.  
  702.  
  703.           - When lines goes up, rather than dumping routing
  704.             table,just waits one minute until all updates have
  705.             been heard.
  706.  
  707.       Path calculation
  708.          o   Dijkstras Algorithm
  709.  
  710.                                   20
  711.                          A _______________ F
  712.                         / \  \
  713.                      3 /   \10\15
  714.                       /     \  \
  715.                     B/___5___\D \E
  716.                      \      /  /
  717.                       \    /  /
  718.                      1 \  /  /5
  719.                         \/  /
  720.                          C /
  721.  
  722.       1.         A       B(A, 3), D(A, 10), E(A, 15). F(A, 20)
  723.  
  724.       2.         A       C(B, 4), D(B, 8), E(A, 15), F(A, 20)
  725.                  |
  726.                  B
  727.  
  728.       4.         A          E(C, 9),  F(A,20)
  729.                  |
  730.                  B
  731.                 / \
  732.                C   D
  733.  
  734.       5.         A
  735.                  |
  736.                  B
  737.                  |
  738.                  C
  739.                 /
  740.                E
  741.  
  742.       Then tree is inverted into a "go here to get to this destination."
  743.  
  744.       For Internet -
  745.  
  746.           Similar algorithm, needs special packet header to
  747.           indicate "exit" gateway to get to destination network.
  748.  
  749.          Update procedure -
  750.             Neighbor interface, neighbors, and delay to neighbor.
  751.  
  752.  
  753. Hinden, Postel, Muuss, & Reynolds                              [Page 13]
  754.  
  755.  
  756.  
  757. RFC 898                                                       April 1984
  758. Gateway SIG Meeting Notes
  759.  
  760.  
  761.             "Next door neighbors" for minimizing traffic.
  762.             Ability to package multiple updates in one average
  763.             explicit Acks.
  764.  
  765.          Path calculation -
  766.            o   Possible to build different trees based on type of
  767.                service.
  768.  
  769.          Forwarding -
  770.            o   Exit Gw
  771.            o   Consistent databases are important.
  772.  
  773.    Multiple Constraint Routing -- SRI - Shacham
  774.  
  775.       Postel:  This was a clear presentation of some of the consequences
  776.       of the idea of type of service routing.  The level of complexity
  777.       of the routing procedure is determined to depend on how many
  778.       catagories of service there are and how many selections there are
  779.       in each catagory.  A few examples were discussed including the
  780.       current type of service parameters of IP.
  781.  
  782.       Muuss:
  783.  
  784.       Both current and proposed ARPANET algorithms provide "best" path
  785.       under single constraint (number of hops, delay).
  786.       Internet will have diverse characteristics, it would be nice to
  787.       consider more than one constraint.
  788.  
  789.         o   Determine a set of measures.
  790.         o   Represent each measure as a single number.
  791.         o   Determine range of values.  (complexity 0(c**n) range of n)
  792.         o   Define path measure as a function of measure of length.
  793.              sum (delay, cost)
  794.              min/capacity, length, security)
  795.  
  796.       If just one cost is used, then SPF (or whatever) can be used for
  797.       each cost.  However, under multiple constraints there is a more
  798.       difficult problem. e.g.:  minimum delay with packet size of at
  799.       least 1000 bytes.
  800.  
  801.       RUMC has been shown to be in the NP complete family.
  802.  
  803.       RUMC needs bigger tables, more processing and routing overhead.
  804.       Its not awful for 2-choice TOS, like in IP.
  805.  
  806.       Table size is random, we have to be prepared for the worst case.
  807.  
  808.       Possible strategies:  flood a "search packet," dropped when
  809.  
  810.  
  811. Hinden, Postel, Muuss, & Reynolds                              [Page 14]
  812.  
  813.  
  814.  
  815. RFC 898                                                       April 1984
  816. Gateway SIG Meeting Notes
  817.  
  818.  
  819.       constraints are not met, see if it makes it though. Good only for
  820.       virtual circuit. Weighted sum (VC only) works only with some
  821.       probability.
  822.  
  823.       TOS is needed for Internet, but the algorithms are costly.
  824.       Complexity for providing TOS IP style is not too high.
  825.  
  826.    FACC Multinet Gateway Routing -- FACC - Cook
  827.  
  828.       Postel:  This approach considered hop count to be an inadequate
  829.       metric for routing decsions in a system of different types of
  830.       networks (e.g., Ethernets, ARPANETs, 2.4Kb lines).  Delay was
  831.       selected as the metric to use.  There are some interesting issues
  832.       in the measurement of delay for some types of networks.  Also, the
  833.       design considers the use of multiple paths when they are avaiable,
  834.       and routing to provide connectivty between the parts of
  835.       partitioned networks.
  836.  
  837.       Muuss:
  838.  
  839.       Routing with a single constraint.
  840.       A network of gateways Access, Transport, or Dual networks.
  841.       Some networks are used as backbones between gateways only.
  842.       
  843.       Routing updates
  844.         Variable length
  845.         Broadcast routing updates
  846.  
  847.       Unitary ends - A - Gw - B - Rest
  848.          Routing for A is really just routing to B
  849.          Neighbor Gws, nets
  850.          Lots and lots of tables
  851.  
  852.    Metanet Gateway -- SRI - Denny
  853.  
  854.       Postel:  This is a project to invent several new addressing
  855.       features for gateways.  In particular, there is a scheme to use an
  856.       option much like the source route option to do multi-addressing of
  857.       IP datagrams.  It seems as if the gateways that implement this
  858.       option will have to know which other gateways do and don't
  859.       implement it.  Also, there was discussion of a gateway to a
  860.       network that is in radio silence, and how to keep TCP connections
  861.       going with hosts that can't talk.  This project is also concerned
  862.       about network reconstitution, security, survivability, congestion
  863.       control, and supporting multimedia data (voice, bitmaps, etc.) in
  864.       applications.  A gateway is being developed in ADA for a MC68000
  865.       machine (SUN), and the initial version of the gateway is to be up
  866.       in May 84.
  867.  
  868.  
  869. Hinden, Postel, Muuss, & Reynolds                              [Page 15]
  870.  
  871.  
  872.  
  873. RFC 898                                                       April 1984
  874. Gateway SIG Meeting Notes
  875.  
  876.  
  877.       Muuss:
  878.  
  879.       Navy internet
  880.         Multimedia mail and conf.
  881.          Radio silence (EMCON)
  882.          Security and Survivability.
  883.  
  884.       EMCON - Causes special problems for EGP and IGP one way nonTCP
  885.       mail delivery.  No Acks. Uses name screen to redirect mail to
  886.       special one-way mail catcher, who then forwards using ordinary
  887.       methods.
  888.  
  889.       Security and survivability
  890.       Access control - "capability" - 32/64 bit key which changes
  891.       frequently (every hour or so)
  892.       
  893.       Reconstitution - Partitioning, coalescing, mobile host
  894.       Test and monitoring - HMP
  895.  
  896.       Gateway target - 68000 in ADA.  Telesoft compiler
  897.  
  898.    Address Mapping and Translation -- UCL - Crowcroft
  899.  
  900.       Postel:  This was a discussion of some of the issues in
  901.       interconnecting networks of different types including the Internet
  902.       and networks in England such as the Universe network.  The
  903.       Universe network is made up of Cambridge Rings at several sites
  904.       linked via a satellite channel.
  905.  
  906.       Muuss:
  907.  
  908.       ARPA - SATNET - NULLNET - UCLNET UNIVERSE Satellite, 3 UCL rings
  909.  
  910.       SAM -
  911.         o   IP switch to several 1822 hosts
  912.         o   IP/universe mapper, overlays UCLNET on universe
  913.         o   Mask and match
  914.               128. 11. code. host
  915.  
  916.       Three types:
  917.  
  918.          1.  Direct:  code --> subnet
  919.               2.  Redirect: 2nd lookup (for multihoming)
  920.               3.  Logical: Logical address into a table of universe
  921.          names.
  922.                            Name lookups give addresses and routes.
  923.  
  924.       IP tunnels through X.25
  925.  
  926.  
  927. Hinden, Postel, Muuss, & Reynolds                              [Page 16]
  928.  
  929.  
  930.  
  931. RFC 898                                                       April 1984
  932. Gateway SIG Meeting Notes
  933.  
  934.  
  935.       BBN Van gateway PSS - IPSS -Telenet - for hosts that can't use
  936.       SATNET.
  937.  
  938.       SAM does access control and multihoming.  Clever Multihoming gives
  939.       host a second address and sends an ICMP/Redirect to force TCP
  940.       connection to go through a different route, but  wind up at same
  941.       place!!!
  942.  
  943.       Wrote EGP in ADA.  It didn't help at all.
  944.  
  945.    Design of the FACC Multinet Gateway -- FACC - Cook
  946.  
  947.       Postel:  This is a distributed multiprocessor machine using a
  948.       special bus network for the interprocessor communication.  The
  949.       softaware is written in C.  The gateways is in an early test
  950.       phase.
  951.  
  952.       Muuss:
  953.  
  954.       RADC program
  955.  
  956.       Started with AUTODIN II, switched to DDN.
  957.       Small to large switching devices.
  958.       DoD uses of PDNs, and partitioned network problems.
  959.       
  960.       Distributed processing architecture -
  961.         Parallel contention, 90M bps bus, 22 wires. Each node has cpu,
  962.         memory, optimal comm line. Wire - OR presentation of address,
  963.         contention happens each time bus becomes free, all requestors
  964.         put out type of msg, pri, and address.   Reads back wire - OR of
  965.         result, and highest gwy wins, sorted by (pri, type, higher
  966.       addr).
  967.         Bus was originally designed for our FAA fail-soft application
  968.         Z-800l w/MMU. Not binary addressing, but unitary (base1)
  969.       One element resolved per bus transaction.
  970.       Boards may be plugged in while running.
  971.       Inherent parallelism in layered protocols.
  972.  
  973.       Interface connector clues board to modem levels and date rate.  Up
  974.       to 100K bps now, soon up to T1 rate.
  975.  
  976.       Multiprocessor approach allows routing calculation to take place
  977.       out-of-band from the measurement of delay and traffic, and allows
  978.       use of more compute power for routing.
  979.  
  980.       Mostly written in C, with some assembler.  Multiprocessor
  981.       operating system, designed from scratch.
  982.  
  983.  
  984.  
  985. Hinden, Postel, Muuss, & Reynolds                              [Page 17]
  986.  
  987.  
  988.  
  989. RFC 898                                                       April 1984
  990. Gateway SIG Meeting Notes
  991.  
  992.  
  993.    SAC Gateway -- SRI - Su/Lewis
  994.  
  995.       Postel:  This was a presentation of the design for the gateways to
  996.       be used in the advanced SAC demo experiments on network
  997.       partitioning and reconstitution, and communication between
  998.       intermingiling mobile networks.  Much of these demonstrations will
  999.       be done with packet radio units and networks.  Some of the ideas
  1000.       are to use a gateway-centered type of addressing and double
  1001.       encapsulation (i.e., an extra IP header) to route datagrams.
  1002.  
  1003.       Muuss:
  1004.  
  1005.       Network dynamics due to component mobility or failure.
  1006.       Mobile host, reconstitution, partitioning.
  1007.         H/W:  11/23
  1008.         S/W:  Some "C" gateway
  1009.         OS:   VMOS (SRI)
  1010.  
  1011.       Gateway-centered addressing, rather than network.
  1012.         Gw host instead of net.host.
  1013.       Double encapsulation:  additional IP header.
  1014.         TCP uses addr as an ID, IP uses it as an ADDRESS (-> route)
  1015.         Need to separate these dual uses of this address field.
  1016.       Incremental Routing (next-hop indication)
  1017.  
  1018.    EGP -- Linkabit - Mills
  1019.  
  1020.       Postel:  A presentation of the EGP design.  EGP has three major
  1021.       aspects, neighbor acquisition, neighbor reachability, and network
  1022.       reachability.  The autonomous system concept was discussed.
  1023.  
  1024.       Muuss:
  1025.  
  1026.       Background, Implementation, Experience, Disparaging Remarks
  1027.  
  1028.       Design goals -
  1029.         o   Established demarcations
  1030.         o   Decouple implementations
  1031.         o   Confine routing loops
  1032.         o   Exchange reachability information
  1033.         o   Provide flow control for connectivity information
  1034.         o   Medium-term lifetime
  1035.  
  1036.       Non goals                       Not trying to do these!
  1037.         o   Flexibility of topology
  1038.         o   Rapid response             Very slow update
  1039.  
  1040.  
  1041.  
  1042.  
  1043. Hinden, Postel, Muuss, & Reynolds                              [Page 18]
  1044.  
  1045.  
  1046.  
  1047. RFC 898                                                       April 1984
  1048. Gateway SIG Meeting Notes
  1049.  
  1050.  
  1051.         o   Adaptive routing
  1052.         o   Common routing metric      No agreement at all
  1053.         o   Load sharing or splitting
  1054.  
  1055.       "Good news travels fast and bad news travels forever."
  1056.       Not for routing, but only provides reachability
  1057.       
  1058.       RFC827 initial mode, RFC888 stub protocol
  1059.  
  1060.       Neighbor acquisition protocol
  1061.          o   2-way shake
  1062.          o   Flow - rates
  1063.          o   Explicit acquisition/cause
  1064.  
  1065.       Neighbor reachability protocol
  1066.          o   Periodic polling
  1067.          o   Parasitic information
  1068.          o   Reachability algorithm Network reachability
  1069.              protocol
  1070.          o   Periodic pulling
  1071.          o   Remote information
  1072.          o   Direct and indirect neighbors
  1073.          o   Indirect internal and indirect external
  1074.              neighbors
  1075.          o   Distance information
  1076.  
  1077.       EGP neighbors do not need to peer with more than one
  1078.       CORE gateway, but you may peer with anybody you wish.
  1079.  
  1080.       Shortcomings -
  1081.          o   Slow reaction due polling
  1082.          o   Tree-structured routing constraint
  1083.            - Rigid topology
  1084.            - Administrative resistance to odering
  1085.            - Lack of adaptive connectivity
  1086.          o   Neighbor acquisition incomplete.
  1087.  
  1088.       Loops between autonomous systems will last a long
  1089.       time, and are a real no-no.
  1090.  
  1091.       System models -
  1092.          o   "Appropriate first hop" criterion
  1093.            - Not useful for implementation
  1094.            - Requires global information
  1095.            - Inadequate for verification
  1096.          o   Graph models
  1097.            - N-graph shows net connectivity
  1098.            - T-graph shows system connectivity
  1099.  
  1100.  
  1101. Hinden, Postel, Muuss, & Reynolds                              [Page 19]
  1102.  
  1103.  
  1104.  
  1105. RFC 898                                                       April 1984
  1106. Gateway SIG Meeting Notes
  1107.  
  1108.  
  1109.            - T-acycloc criterion insures loop-free
  1110.          o   Derived features
  1111.            - Induces spanning tree
  1112.  
  1113.       N-graph
  1114.  
  1115.                                         G1
  1116.                                   A_______________B
  1117.                                  / \            /\
  1118.                             G2  /   \  G3   G4 /  \ G5
  1119.                                /     \        /    \
  1120.                               C------D        E-----F G6
  1121.  
  1122.          AS1 = G2, G3, G6                   A         B
  1123.          AS2 = G1
  1124.          AS3 = G4, G5                 AS1 ----- AS2 ----- AS3
  1125.  
  1126.                                                T-graph
  1127.  
  1128.       Test:  to ensure that there are no cycles
  1129.  
  1130.       Spanning subtree
  1131.  
  1132.       Specification effort - Status report State machine designed
  1133.  
  1134.       Remaining issues -
  1135.         o   Remove extra hop in core system
  1136.         o   Expand tables
  1137.         o   Test backdoor "GGP"
  1138.         o   Resolve specification issues
  1139.         o   Resolve full gateway configuration
  1140.               - Back door connectivity guidance
  1141.               - can only advertise 1 path at a time.
  1142.               - APF rule guidancee
  1143.               - Self organization issues
  1144.         o   Implement and distribute for operational systems.
  1145.  
  1146.    Congestion Control -- FACC - Nagle
  1147.  
  1148.       Postel:  This was a discussion of the situation leading to the
  1149.       ideas presented in RFC 896, and how the policies described there
  1150.       improved overall performance.
  1151.  
  1152.  
  1153.  
  1154.  
  1155.  
  1156.  
  1157.  
  1158.  
  1159. Hinden, Postel, Muuss, & Reynolds                              [Page 20]
  1160.  
  1161.  
  1162.  
  1163. RFC 898                                                       April 1984
  1164. Gateway SIG Meeting Notes
  1165.  
  1166.  
  1167.       Muuss:
  1168.  
  1169.       First principle of congestion control:
  1170.  
  1171.          DON'T DROP PACKETS (unless absolutely necessary)
  1172.  
  1173.       Second principle:
  1174.  
  1175.          Hosts must behave themselves (or else)
  1176.  
  1177.          Enemies list -
  1178.  
  1179.             1.  TOPS-20 TCP from DEC
  1180.             2.  VAX/UNIX 4.2 from Berkeley
  1181.  
  1182.       Third principle:
  1183.  
  1184.          Memory won't help (beyond a certain point).
  1185.  
  1186.          The small packet problem: Big packets are good, small are bad
  1187.          (big = 576).
  1188.  
  1189.       Suggested fix: Rule: When the user writes to TCP, initiate a send
  1190.       only if there are NO outstanding packets on the connection. [good
  1191.       for TELNET, at least] (or if you fill a segment). No change when
  1192.       Acks come back. Assumption is that there is a pipe-like buffer
  1193.       between the user and the TCP.
  1194.  
  1195.       The source quench problem Rule: When a TCP gets an ICMP Source
  1196.       Quench, it must reduce the number of outstanding datagrams on
  1197.       relevant TCP connections.
  1198.  
  1199.       Rule: When a gateway nears overload, before starting to drop
  1200.       packets, send a Source Quench.
  1201.  
  1202.       Node capacity: Each node ought to have one buffer for each TCP
  1203.       connection, plus some for overload.
  1204.  
  1205.       Both fixes really need to be done together, although the first one
  1206.       is often helpful by itself. Side effect: FTPs start off "slowly,"
  1207.       until the first Ack comes back Dave Mills thinks this will
  1208.       increase the mean delay for medium-size interactions. This
  1209.       probably will not work so well for SATNET.
  1210.  
  1211.       Problems about propagation time of links biasing the validity of
  1212.       this result!!
  1213.  
  1214.  
  1215.  
  1216.  
  1217. Hinden, Postel, Muuss, & Reynolds                              [Page 21]
  1218.  
  1219.  
  1220.  
  1221. RFC 898                                                       April 1984
  1222. Gateway SIG Meeting Notes
  1223.  
  1224.  
  1225.    A Gateway Congestion Control Policy--NW Systems - Niznik
  1226.  
  1227.       Postel:  This talk was (for Postel) hard to follow.  There were a
  1228.       number of references to well known results in queuing theory etc,
  1229.       but I could not follow how they were being used.
  1230.  
  1231.       Muuss:
  1232.  
  1233.       Replacements for IMP SPF
  1234.       Topological observations
  1235.       Nodal congestion control policy
  1236.         GMD - control application [from German network]
  1237.         RPN - relational Petri net
  1238.         DCT - dynamic congestion table
  1239.       NCCP performance evaluation
  1240.       Planned GCCP:  Gateway congestion control policy
  1241.  
  1242.       Lots of diagrams and figures.
  1243.  
  1244.       Better throughput than SPF, but somewhat higher delay.
  1245.  
  1246.       Cubic structure of table.
  1247.  
  1248.    DISCUSSION (Postel's personal comments)
  1249.  
  1250.       There was very little organized discussion during the meeting and
  1251.       not really very much question and answer interaction during the
  1252.       presentation.  There was a lot of discussion during the breaks,
  1253.       and at lunch time, and at the end of each day.
  1254.  
  1255.       Some things that occured to me during the meeting that may have
  1256.       been triggered by something someone said (or maybe by the view out
  1257.       the window):
  1258.  
  1259.          Don't design a protocol where you expect to get a lot of
  1260.          messages from a lot of sources at the same time.  For example,
  1261.          don't ask all the hosts on an Ethernet to send you an ack to a
  1262.          broadcast packet.
  1263.  
  1264.          Has anyone worked out in detail the routing traffic costs for
  1265.          the GGP vs the SPF procedures for the actual case of the
  1266.          Internet?
  1267.  
  1268.          How will the fact that thinking of the routing in the core
  1269.          autonomous system is cast in terms of an entry and an exit
  1270.          gateway effect other things?  Will there be special
  1271.  
  1272.  
  1273.  
  1274.  
  1275. Hinden, Postel, Muuss, & Reynolds                              [Page 22]
  1276.  
  1277.  
  1278.  
  1279. RFC 898                                                       April 1984
  1280. Gateway SIG Meeting Notes
  1281.  
  1282.  
  1283.          arrangements between the entry and exit gateway?  Will an
  1284.          autonomous system become a circuit switch connecting pairs of
  1285.          entry/exit gateways?
  1286.  
  1287.          Is TOS routing worth the cost?
  1288.  
  1289.          Should we allow (as a new type of ICMP message) redirects to
  1290.          Gateways?
  1291.  
  1292.          Does making memory larger ever hurt?  If a gateway's memory is
  1293.          full of inappropriately retransmitted TCP segments would it be
  1294.          better if there were less memory?
  1295.  
  1296.          Is there something reasonable to do with source quench at the
  1297.          TCP?  Re: RFC-896.
  1298.  
  1299.          If there are links (or networks) of vastly differing delay and
  1300.          thruput characteristics what impact would an IP level load
  1301.          splitting (say by gateways) have on TCP connections (some of
  1302.          the segments of the connection go one path and others go a
  1303.          different path)?
  1304.  
  1305.          Are any problems avoided (either way) by using double IP
  1306.          headers vs a "source route like" IP option to separate the IP
  1307.          level addressing and routing function from the TCP level
  1308.          end-point naming function of the IP addresses.
  1309.  
  1310.          What bad things could happen from the proposed IP
  1311.          multidestination routing option?
  1312.  
  1313.  
  1314.  
  1315.  
  1316.  
  1317.  
  1318.  
  1319.  
  1320.  
  1321.  
  1322.  
  1323.  
  1324.  
  1325.  
  1326.  
  1327.  
  1328.  
  1329.  
  1330.  
  1331.  
  1332.  
  1333. Hinden, Postel, Muuss, & Reynolds                              [Page 23]
  1334.  
  1335.  
  1336.  
  1337. RFC 898                                                       April 1984
  1338. Gateway SIG Meeting Notes
  1339.  
  1340.  
  1341. MEETING ATTENDEES
  1342.  
  1343.    Mike Accetta - CMU
  1344.    R. Buhr - Canada
  1345.    J. Noel Chiappa - MIT
  1346.    Paul Cook - Ford
  1347.    Jon Crowcroft - UCL
  1348.    Barbara Denny - SRI
  1349.    Jim Forgie  - LL
  1350.    Steve Groff - BBN
  1351.    Phill Gross - Linkabit
  1352.    Kjell Hermansen - NTA
  1353.    Robert Hinden - BBN
  1354.    Patrick Holkenbrink - FACC
  1355.    Ruth Hough - AIRINC
  1356.    Willie Kantrowitz - LL
  1357.    Paul Kirton -ISI
  1358.    Mark Lewis -SRI
  1359.    Liza Martin - MIT
  1360.    Doug Miller - MITRE
  1361.    Dave Mills - Linkabit
  1362.    Mike Muuss - BRL
  1363.    Jose Nabielsky - MITRE
  1364.    Ron Natalie - BRL
  1365.    John Nagle  - Ford
  1366.    Carol Niznick  NW Systems
  1367.    Jon Postel - ISI
  1368.    Joyce Reynolds  -ISI
  1369.    Marshall Rose - UCI
  1370.    Joe Sciortino - AIRINC
  1371.    Linda Seamonson - BBN
  1372.    Nachum Shacham - SRI
  1373.    Alan Sheltzer - UCLA
  1374.    Marvin Solomon  - WISC
  1375.    Zaw-Sing Su - SRI
  1376.    Mitch Tasman - BBN
  1377.  
  1378.  
  1379.  
  1380.  
  1381.  
  1382.  
  1383.  
  1384.  
  1385.  
  1386.  
  1387.  
  1388.  
  1389.  
  1390.  
  1391. Hinden, Postel, Muuss, & Reynolds                              [Page 24]
  1392.  
  1393.